Bochs is written in C++, so you need a C++ compiler on your system. Most platforms have been tested with GNU gcc/g++, but other compilers are known to work too. By now, you should have unpacked your source TAR file or checked out Bochs from CVS. If not, you can return to Downloading Bochs for details. The top level directory of the source code will be referred to as $BOCHS. ($BOCHS contains the files bochs.h and main.cc and subdirectories cpu and bios.)
The standard compile process has three basic steps: configure, make, and make install. Each step is described in a separate section below. The standard compile process is used on all Unix machines, MacOS X, BeOS, and Cygwin (win32). There are separate instructions for compiling for Win32 with Microsoft VC++.
There is a script called configure which tests your machine, C/C++ compiler and libraries to discover what settings should work on your system. If you run configure with no arguments after it, defaults will be used for all settings. To change the settings, you can run configure with options that override the defaults. You can get a list of valid configure options by typing configure --help. One useful configure option is --prefix=directory, which sets the directory in which Bochs will be installed. All the possible configure options are documented in a later section.
Among other things, the configure script tries to detect your platform and which compile options to use. If you want to control this, set these environment variables before running configure: CC, CXX, CFLAGS, CXXFLAGS. Here is an example that sets the environment variables, using bash/ksh[1] syntax:
export CC=egcs export CXX="$CC" export CFLAGS="-Wall -O2 -m486 -fomit-frame-pointer -pipe" export CXXFLAGS="$CFLAGS" |
Once the configure script knows what options are selected, it creates a Makefile in every source code directory, and creates $BOCHS/config.h with all the option values written as preprocessor #defines. Now the sources are ready to compile.
In the Bochs source directory, you will see a series of scripts called .conf.platform. These scripts run the configure script for you, with a set of options that are appropriate for that platform. It is not necessary to use the shortcut scripts; they are simply there to show you an example that the developers have used.
Tip: If a shortcut script is "almost right" for you, just edit it and then run it! If you run a shortcut script, you don't need to run configure manually.
sh .conf.win32-vcpp |
.conf.linux .conf.sparc .conf.macos .conf.macosx .conf.win32-vcpp .conf.win32-cygwin .conf.AIX.4.3.1 .conf.beos |
The make command compiles Bochs. Make is a program used by many software projects that reads the Makefile in each source directory and follows the instructions that it finds there. A Makefile tells which files depend on which other files, what commands to use to compile and link the code, and more. After you have finished the configure step, just type make to build the source code.
The reason that make is so popular is that it is smart about when to compile and when not to compile. If you run make once, it compiles every file. But when you run it again, it checks to see if any source files have been modified; if not, there's nothing to do! For example, the Makefile says that main.o depends on main.cc. Knowing this, it will only compile main.cc if it is newer than main.o.
Of course, make can only do the right thing if the Makefile lists all the dependencies correctly, so human error can sometimes lead make astray. If make refuses to build something that you think it should, or you are getting strange compile errors, try doing make all-clean and then make again. All-clean means to clean up the compiled files in every subdirectory, while make clean means to clean up just the current directory[2]. However, it's important to note that make all-clean leaves the configuration intact. You do not have to run configure again.
If you're really in the mood for cleaning, make dist-clean erases all the configuration information too. In theory, after a dist-clean your directory should look much like when you first untarred it or checked it out. There's usually some extra stuff lying around, but the Makefile tries at least to erase any files that it created.
Once the program has been built, the next step is typically to run make install to copy the executables, documentation, and other required files into a public place so that all users can use it. [3]
This section describes the configure options for Bochs. Perhaps the most important option is --help, since it gives you a list of all the other options. The configure script will detect your platform and choose the default GUI for your platform. If the default choice is not what you want, use the --with-* options to override the default. The options in the first table tell which GUI library is the default for each platform. Starting in version 2.0, you can use multiple --with-* options at once to compile with multiple display libraries, and then choose between them at runtime with the display_library command in the configuration file. Or, you can let the configure script detect which libraries are on your system and use them all, by configuring with --with-all-libs.
Note: The concept of platform detection and default GUIs was added in Bochs 1.4. In Bochs 1.3 and before, the X11 gui was always the default.
Table 3-5. Defaults by Platform
Platform | Default GUI | Extra compile flags |
---|---|---|
win32 or Cygwin | --with-win32 | If using nmake method, compile using cl /nologo /G6 /MT /W3 /GX /DNDEBUG /DWIN32 /D_WINDOWS /O2. If using Visual C++ workspace, see the workspace file for compile settings. See Compiling on Win32 with Microsoft VC++ for instructions. |
MacOS X or Darwin | --with-carbon | -fpascal-strings -fno-common -arch ppc -Wno-four-char-constants -Wno-unknown-pragmas -Dmacintosh |
MacOS 9 or before | --with-macos | none |
BeOS | --with-beos | none |
AmigaOS | --with-amigaos | none |
any other platform | --with-x11 | none |
Table 3-6. Configure Options to Select the Display Library (optional)
Option | Comments | |
---|---|---|
--with-x11 | Use X windows user interface. On many operating systems, Bochs will use X windows by default. | |
--with-win32-vcpp | Use Win32 GUI/Visual C++ environment. This is for running configure on a platform which supports running configure, so that you may then transfer the configured code over to an MS Win32/Visual C++ environment. See the Section called Compiling on Win32 with Microsoft VC++ for details. | |
--with-win32 | Use Win32 GUI, but compile with a Win32/gcc environment such as Cygwin. For Cygwin, see .conf.win32-cygwin for the correct compile options. | |
--with-carbon | Compile for MacOS X with the Carbon GUI. See the .conf.macosx file for the correct MacOS X compile options. | |
--with-amigaos | Compile for Amiga MorphOS. This code is written by Nicholai Benalal. | |
--with-rfb | Use RFB protocol to talk to AT&T's VNC Viewer. The RFB code was written by Don Becker <x-odus@iname.com>, who has a Bochs-RFB web page on his site, http://www.psyon.org/bochs-rfb. RFB mode has been tested in Linux and Win32. | |
--with-sdl | This option enables Dave Poirier's SDL gui interface. To compile with SDL, you must first install the SDL library from libsdl.org. You can either get the source code and compile it yourself, or install the development libraries for your platform (already compiled). SDL is available for many platforms including Win32, Linux, IRIX, MacOS, MacOS X, and BeOS. | |
--with-beos | Use BeOS GUI. The configure script will run natively on BeOS; use this option when doing so. | |
--with-term | Use text-only gui with curses library. Almost certainly won't work right with the debugger or the control panel. | |
--with-macos | Use Macintosh/CodeWarrior environment. This is for running configure on a platform which supports running configure, so that you may then transfer the configured code over to the real compile environment. | |
--with-wx | wxWindows is a cross-platform C++ user interface library which you can download for free at http://wxwindows.org. The wxWindows port of Bochs provides both a graphical configuration interface (for editing bochsrc options) and a display. It was written by Bryce Denney, Don Becker, Dave Poirier, and Volker Ruppert. | |
--with-svga | Use SVGALIB library for Linux. This allows a full-screen text and graphics display without X windows. The SVGALIB port was written by Igor Popik. | |
--with-nogui | No native GUI; just use blank stubs. This is if you don't care about having video output, but are just running tests. | |
--with-all-libs | Automatically detect which libraries are installed on your system and enable them. This option is still experimental; it might enable libraries that are not usable and cause the compile to fail. If you have trouble, just list the --with-* options for the specific display libraries that you want. |
The remaining options can generally be used with any GUI. For each option such as --enable-cdrom, you can also write --disable-cdrom to explicitly turn it off.
Table 3-7. Configure Options
Option | Default | Comments |
---|---|---|
--enable-cpu-level={3,4,5,6} | 5 | Select which CPU level to emulate. Choices are 3,4,5,6 which mean to target 386, 486, Pentium, or Pentium Pro emulation. Pentium Pro support is quite incomplete, so level 5 is the best choice for now. |
--enable-cdrom | yes | Enable use of a real CDROM. The cdrom emulation is always present, and emulates a drive without media by default. You can use this option to compile in support for accessing the media in your workstation's cdrom drive. The supported platforms are Linux, Solaris, OpenBSD, and Windows. For other platforms, a small amount of code specific to your platform must be written. The module iodev/cdrom.cc is the place to add more support. For the most part, you need to figure out the right set of ioctl() calls. |
--enable-sb16={dummy, win, linux, freebsd} | no | Enable Sound Blaster emulation. SB16 output is only supported on Windows, Linux and FreeBSD host systems. The dummy option means to support an SB16, but don't use an output device. So for example, you might use --enable-sb16=linux on a linux host. See section Sound Blaster 16 Emulation for more info. This option also enables the standard PC gameport which is a part of the SB16. If you don't want to use it, you might use --disable-gameport. |
--enable-gameport | no | Enables the standard PC gameport. This option is only necessary if you want to have a gameport, but no SB16 (see above). The connection to a real joystick is currently supported on Linux and win32 only. |
--enable-config-interface | yes | Enables configuration menus when you first start Bochs. The menus let you read in a bochsrc file, edit some options, and save the new bochsrc before starting the simulation. Also enables a runtime menu which lets you change certain settings during simulation. See the config_interface option in bochsrc for how to select between the text interface and wxWindows. |
--enable-new-pit | yes | Enables Greg Alexander's PIT model, written during Summer 2001. This model was written from scratch to be much more complete than the old Bochs PIT model, which was missing many registers and features. If you disable this option, the old PIT model will be used instead. |
--enable-idle-hack | no | Enables Roland Mainz's experimental idle code, which is intended to keep Bochs from always using 100% of CPU time. When Bochs is waiting around for an interrupt, the idle code uses a select() loop and some X11 tricks to wait until user input arrives. This is designed to keep Bochs responsive while still yielding to other processes when Bochs is idle. |
--enable-ne2000 | no | Enable NE2000 network card support. This requires a low-level component to be written for each OS. The NE2000 option is only supported on FreeBSD, OpenBSD, Linux, and Windows 95/98/NT/2K. When enabled and configured, the NE2000 device model can talk to any computer on the network EXCEPT FOR the local host. Exception: Under most circumstances, Bochs can talk to the local host on Windows, and in the ethertap interface for Linux. |
--enable-vbe | yes | Use VGA BIOS Extensions (VBE) by Jeroen Janssen. To take advantage of the VBE, you must tell Bochs to use the LGPL VGA BIOS version 0.3b or higher in the vgaromimage line of your bochsrc file. |
--enable-fpu | yes | If you want to compile bochs to make use of the FPU emulator written by Bill Metzenthen (the one used by the Linux kernel), use this option. |
--enable-plugins | no | Plugins are shared libraries that can be loaded on demand. Example: the serial device is implemented as a plugin. In UNIX, the serial plugin is called libbx_serial.so. When Bochs reads its configuration file, if the serial device is enabled it loads libbx_serial.so. See the Features section for supported platforms. |
--enable-guest2host-tlb | no | support guest to host address TLB for speed |
--enable-repeat-speedups | no | support repeated I/O and memory copy speedups |
--enable-icache | no | support instruction cache for faster execution |
--enable-host-specific-asms | no | support for running native x86 instructions on an x86 machine |
--enable-all-optimizations | no | Turn on the enables for all speed optimizations that the developers believe are safe to use. |
--enable-ignore-bad-msr | no | ignore MSR references that Bochs does not understand, instead of doing a panic |
--enable-x86-64 | no | Add support for AMD's x86-64 instruction set, written by Peter Tattam. The AMD x86-64 support is about 90% complete and is still experimental. The code has been tested on a limited number of test programs. |
--enable-mmx | no | Add support for MMX instructions, written by Stanislav Shwartsman. |
--enable-sse=LEVEL | no | Add support for SSE instructions, written by Stanislav Shwartsman. For SSE only, use --enable-sse=1. For SSE and SSE2, use --enable-sse=2. |
--enable-compressed-hd | no | Add support for compressed disk (not implemented yet). zlib must be installed on your system, as it will be dynamically linked to Bochs. |
--enable-debugger | no | Compile in support for Bochs internal command-line debugger. This has nothing to do with x86 hardware debug support. It is a more powerful and non-intrusive native debugger. Enabling this will of course slow down the emulation. You only need this option if you know you need it. After you have run ./configure, you may want to edit 'config.h' to customize the debugger further. Look at the section entitled 'OPTIONAL DEBUGGER SECTION'. add cross references |
--enable-readline | detected by configure | Compile the debugger with the GNU readline library, which gives command line editing and history. |
--enable-disasm | no | Compile in support for built-in disassembler. Bochs has a built-in disassembler, which is useful if you either run the built-in debugger (--enable-debugger), or want disassembly of the current instruction when there is a panic in bochs. You don't need this option. |
--enable-cpp | no | Use .cpp as C++ suffix. Renames all the .cc files to .cpp for use with compilers which want that, like MS C++ compilers. Don't use this option unless you know you need it. The configure shortcut script for Win32 uses this option. |
--enable-docbook | detected | Build the docbook documentation in doc/docbook. The configure script will enable this option automatically if you have a program called docbook2html installed. |
--enable-iodebug | yes if debugger is on | Dave Poirier has written an experimental interface to the debugger using I/O ports, so that software running in the guest OS can access features of the debugger. You only want this option if you are developing guest OS code for use in Bochs. In other words, most people don't. Also, it should only be used with --enable-debugger. See section in the Developer's Guide for details. |
--enable-x86-debugger | no | X86 debugger support. If the software you run in bochs needs to use the x86 hardware debugging facilities such as DR0..DR8, instruction and data breakpoints etc., then you should use this option. Otherwise don't use it, as it will slow down the emulation. |
--enable-external-debugger | no | enable external debugger support |
--enable-pci | no | Enable limited i440FX PCI support. This is not complete. Don't use this option yet. |
--enable-usb | no | Enable limited i440FX PCI USB support. This is not complete. Don't use this option yet. |
--enable-4meg-pages | no | support 4 megabyte page extensions |
--enable-pae | no | support physical address extensions |
--enable-global-pages | no | support global pages |
--enable-port-e9-hack | yes | Writes to port e9 go to console. Unless you know you want this option, you don't. |
--enable-processors={1,2,3,...,15} | 1 | By changing to more than 1 processor, you enable SMP simulation. This allows you to boot Linux and maybe other OSes in SMP mode, and bochs will simulate all the different CPUs and communication between them. Do not expect this option to speed up your simulation! On the contrary, it has to spend extra time simulating the different CPUs (even if they're mostly idle) and the communication between them. Use it to try out an SMP OS if you don't have an SMP machine, or to debug SMP OS drivers. Click here for more details on SMP in Bochs. |
--enable-apic | no | In an SMP machine, there is an APIC (Advanced Programmable Interrupt Controller) built into each processor and a separate I/O APIC. The APICs are used for inter-processor communication, so they must be enabled for SMP to work. The default is "no" when there is one processor and "yes" when there is more than one processor. Normally, the default is correct and you would never need to type this option. |
--enable-instrumentation=directory | no | Compile in support for instrumentation. This allows you to collect instrumentation data from bochs as it executes code. You have to create your own instrumentation library and define the instrumentation macros (hooks in bochs) to either call your library functions or not, depending upon whether you want to collect each piece of data. [Kevin wrote: I broke some of the hooks when I recoded the fetch/decode loop.] |
--enable-simid={0, 1} | 0 | CPU simulator ID. You likely don't need this option. If you are using bochs to cosimulate, that is to run multiple simulators in parallel so that you can compare results and check for divergence, each simulator needs an ID. When you only have one CPU simulator (as usual) the default of 0 is fine. [Kevin wrote: I use this option occasionally to run 2 versions of bochs against each other and check for divergence, to find bugs etc. This option gets broken more than not due to architectural changes, and I usually end of fixing it each time I use it.] |
--enable-num-sim={1, 2} | 1 | Number of CPU simulators. The default of 1 is likely what you want, so don't use this option. It is for assigning an ID to the simulator, for cosimulation described above. |
--enable-time0=n | no | Start CMOS clock at at time0 of n instead of using time(). You likely don't want this option. When debugging, it is very helpful to have deterministic execution, and the clock is something that can skew determinism. If you supply this option, pass it a value returned by the time(NULL) call, relating to the time you want bochs to start the CMOS clock from. For instance, '--enable-time0=917385580'. If you use this option but don't provide a value, configure uses a default value. Note that the time0 option in .bochsrc will override this value. Without this option, the CMOS clock uses a time0 based on the value of time(NULL), which is probably what you want. |
--enable-xpm | yes | Enables the check for the XPM library. This option is only valid if the x display library is enabled (--with-x11). |
user$ ls -l bochs-1.2.1.tar.gz -rw-rw-r-- 1 user user 887993 Sep 15 23:24 bochs-1.2.1.tar.gz user$ gunzip -c bochs-1.2.1.tar.gz | tar -xvf - bochs-1.2.1/ bochs-1.2.1/bios/ bochs-1.2.1/bios/BIOS-bochs-2-processors bochs-1.2.1/bios/Makefile.in . . . bochs-1.2.1/patches/NOTES bochs-1.2.1/patches/patch.4meg-pages bochs-1.2.1/patches/patch.goswin-changes user$ cd bochs-1.2.1 user$ ./configure --enable-cdrom creating cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes . . . creating misc/Makefile creating dynamic/Makefile creating fpu/Makefile creating config.h user$ make cd iodev && \ make CC="gcc" CXX="c++" CFLAGS="-g -O2 " CXXFLAGS="-g -O2 " LDFLAGS="" LIBS="" X_LIBS="-L/usr/X11R6/lib" X_PRE_LIBS="-lSM -lICE" prefix="/usr/local" exec_prefix="/usr/local" bindir="/usr/local/bin" infodir="" libiodev.a make[1]: Entering directory `/tmp/bochs-1.2.1/iodev' c++ -c -g -O2 -I.. -I../instrument/stubs devices.cc -o devices.o c++ -c -g -O2 -I.. -I../instrument/stubs pic.cc -o pic.o c++ -c -g -O2 -I.. -I../instrument/stubs pit.cc -o pit.o c++ -c -g -O2 -I.. -I../instrument/stubs unmapped.cc -o unmapped.o c++ -c -g -O2 -I.. -I../instrument/stubs cmos.cc -o cmos.o . . . echo done done c++ -o bochs -g -O2 main.o load32bitOShack.o state_file.o pc_system.o osdep.o \ iodev/libiodev.a \ cpu/libcpu.a memory/libmemory.a gui/libgui.a \ fpu/libfpu.a \ -L/usr/X11R6/lib -lSM -lICE -lX11 gcc -c -g -O2 -I. -Iinstrument/stubs misc/bximage.c -o misc/bximage.o c++ -o bximage -g -O2 misc/bximage.o user$ su root# make install cd iodev && \ make CC="gcc" CXX="c++" CFLAGS="-g -O2 " CXXFLAGS="-g -O2 " LDFLAGS="" LIBS="" X_LIBS="-L/usr/X11R6/lib" X_PRE_LIBS="-lSM -lICE" prefix="/usr/local" exec_prefix="/usr/local" bindir="/usr/local/bin" infodir="" libiodev.a make[1]: Entering directory `/tmp/bochs-1.2.1/iodev' . . . /usr/local/bochs/1.2.1/install-x11-fonts Looking for fonts to install... font/ Looking for X11 Font Path... /usr/lib/X11/fonts Installing vga.pcf... ok (it was already there) Running mkfontdir... Done installing Bochs fonts for X11. root# exit user$ _ |
The standard compile uses the configure script, but the Windows platform cannot run the configure script natively. The current solution to this problem is that the Bochs configure script must be run on a different platform that does support shell scripts, with options that cause it to configure for a Win32 platform instead of the native one. Many people have access to a UNIX machine that could run the configure script, or you can use Cygwin to run the configure script [4].
Download the Bochs sources on a machine that can run shell scripts. Edit the configure shortcut script .conf.win32-vcpp if you want to adjust the configure options. Then type these commands in the Bochs source directory:
sh .conf.win32-vcpp make win32_snap |
When you have the Win32 sources transferred to a Windows machine with VC++, find the workspace file called bochs.dsw and load it in VC++. Choose Project:Set Active Project and be sure that "bochs" is selected. Then choose Build:Build bochs.exe. This will build all the required libraries (iodev, cpu, etc.) and the auxiliary programs bximage.exe, bxcommit.exe and niclist.exe.
Using workspaces is easy and intuitive, but there is one caveat. The workspaces come directly out of a ZIP file in build/win32/workspace.zip, and they are not controlled by the configure script. When you compile with certain configure options (e.g. --with-sdl) you need to link with additional libraries. For now you must add them to the VC++ workspace by hand. In version 2.0, we have improved the situation considerably by adding #if...#endif around every optional file and including nearly every Bochs source file in the workspace. This solves the problem of having to manually add source files to the workspace when you turn on configure options such as --enable-debugger. The problem of adding link libraries remains unresolved.
Tip: To compile with the Bochs debugger enabled, add "--enable-debugger" to the configure line in .conf.win32-vcpp before running it. No modifications to the workspace are necessary.
An alternative way to compile is to run nmake.exe in an MS-DOS window. Instead of using the workspace files, nmake uses the Bochs makefiles that are generated by configure. The workspace file was new in version 1.3; before that, nmake was the only way to compile Bochs in VC++. Starting with version 1.4, the workspace is used to build the release binaries.
The make install for Win32 is presently broken. In the future, a make install that runs in Cygwin may be provided.
Cygwin is a free Unix-like environment for Windows written by Steve Chamberlain and now maintained by RedHat, Inc. You can download it from www.cygwin.com. Because Cygwin supports the configure script and uses GNU gcc/g++, you can use the standard compile process. The configure script should automatically detect Cygwin and add "-mno-cygwin -DWIN32" to the compiler options. You should get a working Bochs if you just type:
configure make |
sh .conf.win32-cygwin make |
--enable-cdrom --enable-sb16=win --enable-ne2000 --enable-vbe |
It is possible that this hasn't been tried since 1999. In theory, you run sh .conf.macos on a Unix box to build the makefiles and headers, copy the whole thing over to a Mac, and then use CodeWarrior to compile. Since it hasn't been tested in so long, it is quite likely that some work is needed to bring the Mac port up to date.
If you are interested and have the required MacOS development tools, please let us know. Someone requests a MacOS port almost once a month, but none of the developers know how to help them.
The port to MacOS X with Carbon API by Emmanuel Mailliard is quite new, and the configure and makefile support was added by Bryce Denney. You will need the compiler and libraries from the development tools CD. Bochs should configure and compile with the Carbon GUI if you simply type:
configure make |
sh .conf.macosx make |
On MacOS X the default GUI is the Carbon interface, but you can also try other Bochs GUIs. Use --enable-x11 for X windows, --enable-rfb for VNC/RFB, or --enable-sdl for SDL.
Kevin Lawton ported Bochs to BeOS. Bernd Korz has taken over the port, and is working on raw cdrom and raw floppy support. As of Bochs 1.4, it should compile if you just type "configure && make", because configure will detect the BeOS platform and assume you want the BeOS GUI. Optionally, you can use the configure shortcut script for BeOS, .conf.beos. This shortcut script uses the SDL gui by default.
Nicholai Benalal created this port to MorphOS running on Amiga. It should compile with
configure && make |
Don Becker's RFB interface allows you to view the Bochs display with the AT&T's VNC Viewer. The protocol used between a VNC server and a VNC viewer is called RFB. Because the RFB code in Bochs is written with portable network socket and POSIX thread code, it can be compiled on many platforms. No additional libraries are required. To try it, type:
configure --with-rfb make |
Dave Poirier has written an SDL interface for Bochs. Simple DirectMedia Layer, or SDL, is a cross-platform multimedia library distributed from libsdl.org. SDL supports Win32, Linux, IRIX, MacOS, MacOS X, BeOS, and AmigaOS.
To compile Bochs with the SDL interface you need to download the SDL development library. Either get the development library for your platform, or download the sources and compile it yourself. Then, go into the Bochs directory and type:
configure --with-sdl make |
Note: This has only been tested on Linux at the time this documentation was written.
To compile in Microsoft VC++, you have to configure on a different system. Here's the procedure:
- On a machine that can run shell scripts, such as Cygwin, run configure --target=pentium-windows --with-sdl make win32_snap - Copy the resulting ZIP file to your Windows box and unzip it. - Load up workspace called bochs.dsw in VC++ 6.0 - Double click "gui files" - Remove gui/win32.cpp from the project, and add gui/sdl.cpp instead. - Edit the settings of "gui files". Under C/C++ tab, category=preprocessor, additional include directories, add the directory where SDL/SDL.h can be found. - Edit the settings of the "bochs files" project. Under the Link tab, category=General, add SDL.lib to object/library modules list. Then in category=Input, add the path of SDL.lib to additional library path. Click ok. - Select Build:Build Bochs.exe |
RPM stands for "RedHat Package Manager." An RPM is a compressed file containing files to be installed on your system. Bochs has a special shell script called make-rpm that helps to build an RPM of Bochs. Start with a clean source directory. Edit .conf.linux first if you want to adjust the configure options. Then, type:
./build/redhat/make-rpm | tee /tmp/build.txt |
Note: In the past, you had to build rpms as root, but as of version 2.0 you can build them as a normal user.
what if configure fails? - tar up config.* and send to bochs-testing@tlw.com - report the problem with a source forge bug report. what if make fails? - try make dist-clean, and run configure and make again - use configure options to disable options. For example, if errors in fpu/fpu_system.h, you could try --disable-fpu. - search for the error on the Bochs website (bug reports, patches) - if familiar with C++, many minor problems can be corrected - move to more stable code. if it's CVS, see if a release version will compile. Report problem to bochs-developers. - report the problem with a source forge bug report. |
[1] | The syntax for bash and ksh is given. In csh and variants, use the syntax setenv VARIABLE value to change environment variables. Do not use an equal sign for csh! |
[2] | This is different from the terminology of some other projects, and it may cause confusion. Sometimes "clean" implies that all subdirectories are affected. |
[3] | We should mention what gets installed, and where. /usr/local/bin/bochs (and bximage, bxcommit) /usr/local/share/bochs/* /usr/local/share/man/man1/bochs*.1 (and bximage.1, bxcommit.1) make install_dlx option |
[4] | Because Bochs depends so much on the configure script, if you are doing much win32 Bochs development, you should consider downloading Cygwin so that you can run the configure step natively. |
[5] | If the source directory is /home/joe/bochs-win32, the resulting .zip file is in /home/joe/bochs-win32.zip. |